home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1156 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: Gem List
  3. Date:     Wed, 27 Jul 1994 21:53:24 -0600
  4. Precedence: bulk
  5.  
  6. Hello Warwick,
  7.  
  8. >Michel Forget wrote:
  9. >>
  10. >>This is not a good approach.  It limits the number of windows to 20.
  11. >>MultiTOS can have many more than that, and so can Geneva.  A much
  12. >>better (though confusing) solution is to use a linked-list, or a
  13. >>dynamically allocated array.  That way the list can grow indefinitely.
  14. >
  15. >In GEM++, I use a linked list, and go to the trouble of maintaining the
  16. >list to be in the same order as the windows.  I'm still not sure how
  17. >useful this is, since I could call wind_find(), then search an
  18. >unordered list.  Comments?
  19.  
  20. In MasterBrowse, I use an unordered double-linked list.  There is no
  21. real advantage to it (using wind_find() to get the window handle and
  22. then matching that to the handle in the list of browsers) other than
  23. that it is pretty readable.  You might save a little time, but I'm
  24. not positive.
  25.  
  26. >I also never hold onto a window handle if the window is not open.
  27. >This means keeping my own copies of the window sizes, but again,
  28. >that hasn't been a problem.  Good for older TOSes.  Comments?  (Hey,
  29. >maybe everyone does these things - I've not looked at the details of
  30. >many libraries).
  31.  
  32. I actually do the same thing you do.  It is really the only way to keep
  33. track of an item's (object, or whatever you want to call it) position if
  34. you destroy the window when it is closed.
  35.  
  36. [about changing objc_edit()/form_keybD()]
  37. >This is 100% true.  The trouble is, those situations (eg. to allow
  38. >scolling textfields) force you to write all the code that can be reused
  39. >in plain textfields anyway.  Because functionality provided by TSRs
  40. >are not extensible.  Scrolling text fields are very important (eg. if
  41. >the field is supposed to hold a filename, it is usually restricted
  42. >to 70 characters - that can be as little as 4 directories deep.  It
  43. >would be difficult (but not impossible) for a TSR to support this,
  44. >since it cannot normally know how large a field the program can
  45. >handle.  So while TSR's might look like a nice solution, they have
  46. >trouble providing what a library can provide.
  47.  
  48. You should be able to do scrolling text fields without replacing objc_edit(),
  49. right?  I have not tried it, but it seems straight-forward.  Your point is
  50. taken, though.  There are times when replacing objc_edit()/form_keybd()
  51. with your own calls is required.  If you can, though, it should be left
  52. alone.  That way you might be able to support internally-sizeable text
  53. fields (nonsense, really -- just an example) even if you do not have the
  54. code written for it.
  55.  
  56.  
  57. -- 
  58. Michel Forget           \\   mforget@elfhaven.ersys.edmonton.ab.ca    //
  59. Electric Storm Software  \\  ess@tibalt.supernet.ab.ca               //
  60. PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F3 4A C6 AD 6E 02 71 85
  61.